AWS CLI ทำงานอย่างไร ? พร้อมการจัดการที่ปลอดภัย และ รวมข้อดีข้อเสีย

ในช่วงไม่กี่ปีที่ผ่านมา มีหลายเหตุการณ์ที่เกิดขึ้นด้านความปลอดภัยร้ายแรง เช่น ค่าธรรมเนียมการใช้งานจำนวนมากและการรั่วไหลของข้อมูลที่สงสัยว่าเกิดขึ้นจากการบุกรุกบัญชีเนื่องจากการรั่วไหลของ Access key เข้าถึง AWS ดังนั้นเราจึงเริ่มโครงการเพื่อแนะนำความพยายามของเราในการที่จะปรับปรุงความปลอดภัยที่เกี่ยวข้องกับการดำเนินการ Access key ภายในบล็อกของเรา

#Classmethod Thailand

#Thai Language

#AWS

#AWS-Thai

#AWS CLI

Chawish Tilakul

2022.12.16

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS Access Key Security Awareness คืออะไร ?

ดังนั้นเราจึงเริ่มโครงการเพื่อแนะนำความพยายามของเราในการที่จะปรับปรุงความปลอดภัยที่เกี่ยวข้องกับการดำเนินการ Access key ภายในบล็อกของเรา

เมื่อใช้ Access key ในการเข้าถึง เราต้องเข้าใจด้วยว่ามีความเสี่ยงในการใช้งานอย่างอยู่และควรคำนึงถึงการใช้มาตรการรักษาความปลอดภัยล่วงหน้าก่อนใช้งานอย่างเหมาะสม
และนี้คือบทความภาษาไทยที่อธิบายเกี่ยวกับความอันตรายของ AWS Access keys เพื่อให้ท่านนำไปศึกษาเพิ่มเติมครับ
[ข้อควรระวัง] เกี่ยวกับการที่ Access Key หลุด(รั่วไหล) และถูกนำไปใช้โดยไม่ได้รับอนุญาต

AWS CLI, จะถูกใช้งานที่ไหนได้บ้าง ?

โดยทั่วไปคนส่วนใหญ่จะใช้ 4 ประเภทต่อไปนี้

local terminal
การเชื่อมต่อไป EC2 เพื่อใช้ SSH
การเชื่อมต่อไป EC2 เพื่อใช้ SSM (session manager)
การใช้งาน AWS Cloud Shell

แล้วมีความแตกต่างกันอย่างไร ? ผมคิดว่ามันขึ้นอยู่กับสถานการณ์ในการใช้งาน แต่ในครั้งนี้ผมจะพยายามเปรียบเทียบจาก 3 มุมมองนั้นก็คือ

1.การจัดการ Access key
2.การทำ log record
3.การสร้างและจัดการ Environment
(*ในบทความครั้งนี้ใช้งาน Linux เป็นหลัก)

summary first

place	IAM access key	Shell operation log	AWS API operation log	Environment construction and operation
local terminal	△ จำเป็น	△ ต้องจัดเตรียมเอง	○ ตรวจสอบได้จาก IAM User	○ (ขึ้นอยู่กับกฏของ workspace และอื่นๆ)
EC2 + SSH	○ ไม่จำเป็น	△ ต้องจัดเตรียมเอง	(△-) ต้องการกลไกเพื่อระบุผู้ใช้เข้าสู่ระบบ EC2	△ การจัดการ EC2
EC2 + SSM	○ ไม่จำเป็น	○ มีฟังก์ชันเอาต์พุตอัตโนมัติไปยัง S3, CloudWatchLogs	(△+) การระบุตัวตนจากประวัติและ log Shell	△ การจัดการ EC2
Cloud Shell	○ ไม่จำเป็น	△ ต้องจัดเตรียมเอง	○ ตรวจสอบได้จาก IAM User	○ ไม่ใช้งาน

EC2 + SSH, EC2 + SSM, CloudShell ไม่จำเป็นต้องใช้ access keys
เมื่อใช้งานกับ local terminal เราต้องระมัดระวังเกี่ยวกับการจัดการ access keys
EC2 + SSM มีความสามารถในการทำ logging ได้ดี
CloudShell ไม่จำเป็นต้องใช้งานการจัดการและการสร้าง environment

การจัดระเบียบวิธีการเชื่อมต่อของแต่ละรายการ

Local terminal

สำหรับ terminal ภายใน การทำงานพื้นฐานคือการใช้ Access key เข้าถึง

แนวทางปฏิบัติที่ดีที่สุดสำหรับการใช้ Access key เพื่อเข้าถึง AWS ที่แสดงไว้ด้านล่างแต่โดยพื้นฐานแล้วจะมีข้อความว่า "ในกรณีส่วนใหญ่เราไม่จำเป็นต้องใช้ Access key ในการเข้าถึงระยะยาวที่ไม่มีวันหมดอายุ (เช่น Access key ที่เข้าถึงผู้ใช้ IAM)"

ส่วนใหญ่เราไม่จำเป็นต้องใช้ Access Key สำหรับใช้งานระยะยาวที่ไม่มีวันหมดอายุ (เช่น Access key เพื่อเข้าถึงของผู้ใช้ IAM) . เราสามารถสร้าง IAM role และสร้างข้อมูลรับรองความปลอดภัยชั่วคราวได้ ข้อมูลรับรองความปลอดภัยชั่วคราวประกอบด้วย ID Access key และ Secret access key แต่ยังมี token ด้านความปลอดภัยที่ระบุเมื่อข้อมูลรับรองหมดอายุ

Quote: Best Practices for Managing AWS Access Keys - AWS General Reference
โดยเฉพาะอย่างยิ่งเราต้องการหลีกเลี่ยงการใช้ Access Key เพื่อเข้าถึงสิทธิ์ขั้นสูง เช่น การดำเนินการใช้งาน EC2 และการสร้างผู้ใช้ IAM ด้วยวิธีนี้

เพื่อให้สอดคล้องกับแนวทางปฏิบัติที่ดีที่สุด เราแนะนำให้ผู้ใช้ IAM มีสิทธิ์น้อยที่สุดเท่าที่จะทำได้ และเปลี่ยนบทบาทเป็นบทบาทที่มีสิทธิ์ที่กว้างขึ้นโดยใช้ MFA แทน

การจัดการเพื่อเชื่อมต่อ EC2 ผ่าน SSH

นี่เป็นการดำเนินการที่ใช้ SSH เพื่อเชื่อมต่อกับ EC2 Instance ที่สร้างขึ้นเพื่อการจัดการและ ใช้ IAM role (โปรไฟล์อินสแตนซ์) ที่แนบมากับ EC2

ไม่จำเป็นต้องออกรหัสเพื่อใช้ในการเข้าถึง

อย่างไรก็ตาม นอกจาก IAM แล้ว ยังมีข้อควรพิจารณาเพิ่มเติม เช่น ความจำเป็นในการเปิดพอร์ตสำหรับ SSH / ความจำเป็นในการจัดการผู้ใช้ OS และคีย์ SSH
สามารถศึกษาข้อมูลเกี่ยวเพิ่มเติมเกี่ยวกับการเชื่อมต่อ EC2 ผ่าน SSH ได้จากลิ้งค์ด้านล่างนี้เลยครับ
【Update】วิธีติดตั้ง Amazon Linux 2 บน EC2 และเชื่อมต่อเซิร์ฟเวอร์ด้วยโปรแกรม PuTTY

การจัดการเพื่อเชื่อมต่อ EC2 ผ่าน SSM

เป็นการดำเนินการที่เชื่อมต่อกับอินสแตนซ์ EC2 ที่สร้างขึ้นสำหรับการจัดการโดยใช้ตัวจัดการเซสชัน SSM และ ใช้ IAM role (โปรไฟล์อินสแตนซ์) ที่แนบมากับ EC2

ไม่ต้องใช้ Key Access ในการเข้าถึง สามารถศึกษาข้อมูลเพิ่มเติมได้จากลิ้งค์ด้านล่างนี้นะครับ
การใช้งาน SSM เชื่อมต่อเข้า EC2 Instance โดยไม่ต้องมี Inbound

Cloud Shell

เราสามารถเริ่มใช้งานได้ทันทีโดยคลิกปุ่มที่ด้านบนขวาของ AWS Management Console การดำเนินการของเชลล์สามารถทำได้ด้วยสิทธิ์ของผู้ใช้ IAM (Role) ที่ล็อกอินเข้าสู่คอนโซลการจัดการ ไม่ต้องใช้ Access key เข้าถึง
[บทความที่เกี่ยวข้องภาษาญี่ปุ่น] AWS CloudShell บริการใหม่ที่รอคอยมานานเปิดตัวแล้ว! #คิดค้นใหม่ | Developer IO

มุมมองที่ 1: IAM Access Key

ครั้งนี้ เราประเมินว่าเป็นวิธีการที่ไม่ใช้ Access key เข้าถึง IAM ตามแนวทางปฏิบัติที่ดีที่สุด อีกครั้ง หากเราใช้ Access key เข้าถึง ให้สิทธิแก่ผู้ใช้ IAM ในจำนวนที่น้อยที่สุดเท่าที่จะเป็นไปได้ และตั้งค่า MFA ด้วย

place	IAM access key
local terminal	△ จำเป็น
EC2 + SSH	○ ไม่จำเป็น
EC2 + SSM	○ ไม่จำเป็น
Cloud Shell	○ ไม่จำเป็น

มุมมองที่ 2: การบันทึกการทำงาน (Operation logging)

โดยมีการเก็บบันทึกข้อมูล 2 แบบ คือ

1.Shell operation log
2.AWS API operation log

Shell operation log

นอกเหนือจาก SSM เราต้องเตรียมการตั้งค่า terminal และ SSH Client ของเราด้วยเพื่อเรียกใช้คำสั่งสคริปต์ ฯลฯ

place	IAM access key	Shell operation log
local terminal	△	△ ต้องจัดเตรียมเอง
EC2 + SSH	○	△ ต้องจัดเตรียมเอง
EC2 + SSM	○	○ มีฟังก์ชันเอาต์พุตอัตโนมัติไปยัง S3, CloudWatchLogs
Cloud Shell	○	△ ต้องจัดเตรียมเอง

ที่นี่ดูเหมือนว่า "การเชื่อมต่อผ่าน SSM" ซึ่งมีฟังก์ชันเดียวในการรวมบันทึกโดยอัตโนมัติจะเป็นผู้ชนะ

เราสามารถค้นหาบทความที่อธิบายคุณลักษณะนี้โดยละเอียดได้ที่นี่

[บทความที่เกี่ยวข้องภาษาญี่ปุ่น] Log AWS Systems Manager Session Manager shell operations | DevelopersIO

AWS API operation log

สามารถตรวจสอบบันทึกการทำงานของ AWS API ผ่าน CLI จาก CloudTrail ได้ทุกรูปแบบ เราสามารถตรวจสอบได้ว่าใครเข้าถึง API ที่เกี่ยวข้องและเมื่อใด

ในการทดสอบ เราเรียกใช้ STS GetCallerIdentity API และจัดเรียงเอาต์พุต CloudTrail * ข้อมูลการตรวจสอบสิทธิ์ IAM ดั้งเดิมสำหรับ Access key เข้าถึง, SSM และ CloudShell ได้รับมาพร้อมกับ Switch role

เราได้วงกลมจุดต่าง ความแตกต่างที่สำคัญคือที่อยู่ IP ของผู้ออกและความสะดวกในการติดตามว่าใครเข้าถึง API

เราคิดว่าสิ่งที่ น่าสงสัยเป็นพิเศษคือ "ใครเป็นคนโจมตี API"

สำหรับการเชื่อมต่อจาก terminal ในเครื่อง สามารถระบุผู้ใช้ IAM ดั้งเดิมได้โดยการติดตาม CloudTrail ตามชื่อเซสชัน Swirch role CloudShell ใจดีพอที่จะแสดงชื่อผู้ใช้ IAM ของ role ก่อนสลับ (เป็นชื่อเซสชัน)

ในทางกลับกัน SSH ไม่สามารถรับข้อมูลที่เกิน ID อินสแตนซ์ EC2

SSM ยังบันทึกรหัสอินสแตนซ์ EC2 แต่ SSM สามารถทราบผู้ใช้ที่เชื่อมต่อในช่วงเวลาที่เกี่ยวข้องจากบันทึกเซสชันที่ผ่านมาดังนี้ หากเราเก็บประวัติการทำงานของเชลล์ดังกล่าวแล้ว เราจะสามารถระบุตัวตนได้จากที่นั่น

มุมมองที่ 3: การสร้าง Environment และการดำเนินงาน

local terminal

เราต้องติดตั้ง AWS CLI และตั้งค่าไฟล์รับรองให้เป็น Access key
ระดับความยาก-ง่ายจะแตกต่างกันไปในแต่ละคน แต่อาจเป็นปัญหาตามมาในส่วนของ environment ซึ่งแต่ละคนก็มีความต้องการที่จะจัดการ software ต่างๆที่ทำการติดตั้งภายใน local environment

EC2 + SSH

ต้องมีการติดตั้ง AWS CLI (AMI หลายๆตัวในปัจจุบันก็ทำการติดตั้งเป็นที่เรียบร้อยแล้ว)
SSH เป็นการเชื่อมต่อพื้นฐานที่เกี่ยวข้องกับตัวผู้ใช้และการใช้ SSH key management และ EC2 instance operation

EC2 + SSM

ต้องมีการติดตั้ง AWS CLI (AMI หลายๆตัวในปัจจุบันก็ทำการติดตั้งเป็นที่เรียบร้อยแล้ว)
SSM จำเป็นที่จะต้องตั้งค่าเพื่อการดำเนิน Instance EC2 ให้เกิดขึ้น

Cloud Shell

ในส่วนนี้ไม่จำเป็นก็ใช้งานก็ได้ (ถ้าเราสามารถเข้าสู่ระบบใน AWS Management Console)

So this is what happened.

place	IAM access key	Shell operation log	AWS API operation log	Environment construction and operation
local terminal	△	△	○	○ (ขึ้นอยู่กับกฏของ workspace และอื่นๆ)
EC2 + SSH	○	△	(△-)	△ การจัดการ EC2
EC2 + SSM	○	○	(△+)	△ การจัดการ EC2
Cloud Shell	○	△	○	○ ไม่จำเป็นต้องใช้

สรุป

นี้คือสรุปของเนื้อหาทั้งหมดนะครับ - EC2 + SSH, EC2 + SSM, CloudShell ไม่ต้องการ Access key เข้าถึง - เมื่อใช้ local terminal เราต้องระมัดระวังเกี่ยวกับการจัดการ Access key เข้าถึง !! - EC2 + SSM มีความสามารถในการบันทึกที่ยอดเยี่ยม - CloudShell ไม่ต้องการการสร้างสภาพแวดล้อมและการดำเนินการ

ดังนั้น จึงมีการเปรียบเทียบข้อดีและข้อเสียตามการใช้งานจาก AWS CLI ของทั้งสามมุมมอง

Access key ปกติที่มีความเสี่ยงต่อการรั่วไหล หากเราจำเป็นต้องการป้องกันความเสียหายจากการรั่วไหลของข้อมูลและใช้งาน Access key เข้าถึงที่ปลอดภัย ให้พยายามตรวจสอบให้แน่ใจว่าได้กำหนด role และได้รับมอบอำนาจในการจัดการ Access key ขั้นสูงสุดแล้ว

ซึ่งหากเราต้องการทำบางสิ่งด้วยกลไกต่างๆและไม่ต้องคำนึงถึงอุปกรณ์แต่ละชิ้น ผมขอแนะนำให้พิจารณาใช้ SSM หรือ CloudShell โดยไม่ต้องออก Access key เพื่อเข้าใช้งานเลย

เนื้อหาในบล็อกนี้ทั้งหมด ผมแปลและเรียบเรียงมาจากบล็อกต้นฉบับภาษาญี่ปุ่นของคุณ Kato-Saori สามารถไปติดตามเนื้อหาใหม่ได้ที่โปรไฟล์ของเขาได้เลยนะครับ และนี้ก็เป็นบทความต้นฉบับที่ผมนำมาแปลในบล็อกนี้ครับ
- AWSのCLI作業はどこで行う？安全に管理するパターンとメリデメ集
หวังว่าทุกท่านจะได้รับความรู้และความเข้าใจ การตั้งค่าความปลอดภัยต่างๆและนำมาปรับใช้เพื่อเสริมความปลอดภัยในการใช้งาน AWS ให้รัดกุมมากยิ่งขึ้นนะครับ ขอบคุณครับ